home *** CD-ROM | disk | FTP | other *** search
- Path: longway!std-unix
- From: ahby@bungia.bungia.mn.org (Shane P. McCarron)
- Newsgroups: comp.std.unix
- Subject: Standards Update, Part 2: C Language Standard
- Message-ID: <269@longway.TIC.COM>
- Date: 11 Dec 88 00:07:13 GMT
- Sender: std-unix@longway.TIC.COM
- Reply-To: Shane P. McCarron <ahby@bungia.bungia.mn.org>
- Lines: 183
- Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
-
- [ These Standards Updates are published after each IEEE 1003
- meeting, and are commissioned by the USENIX Association.
- See Part 1 for contact information. -mod ]
-
-
-
- An update on UNIX|= Standards Activities - Part 2
-
- C Language Standard
-
- November 18, 1988
-
- Shane P. McCarron, NAPS International
-
- C Language Standard
-
- X3J11 (ANSI C standardization committee) met 26-30 Sep. 1988
- at Sunnyvale, CA. Principal business of the meeting was to
- respond to comments received during the third round of
- formal public review, which had closed earlier that month.
- In addition to the 15 letters formally registered with
- CBEMA's X3 Secretariat, 27 unregistered letters were
- included. There were 632 items contained in these 42
- letters. In order to address them all, the committee was
- divided into response preparation subgroups, each of which
- tackled a subset of the total list of items. From time to
- time, the whole committee reassembled to hear issues that
- the subgroups were not able to completely resolve by
- themselves. In several cases a straw vote was taken to
- determine the sense of the committee. The resulting
- responses were formatted to produce the official X3J11
- Response Document.
-
- At the Sunnyvale meeting, several editorial changes to the
- draft standard were approved. The working definition of
- ``editorial'' was: A change is editorial if it clarifies
- the original intent of the committee; it is substantive if
- it changes the committee's intent.
-
- There were several issues that were of particular interest
- to the UNIX/POSIX community:
-
- o+ A change was made that clarified the ability of an
- application to portably reestablish a signal handler
- for the signal that caused entry to the handler. This
- is indeed allowed under the standard. The important
- passage reads:
-
- If the signal occurs other than as a result of
- calling the abort or raise function, the behavior
-
- __________
-
- |= UNIX is a registered trademark of AT&T in the U.S. and
- other countries.
-
-
- - 2 -
-
- is undefined if the signal handler calls any
- function in the standard library other than the
- signal function itself (with a first argument of
- the signal number corresponding to the signal that
- caused the invocation of the handler) or refers to
- any object with static storage duration other than
- by assigning a value to a static storage duration
- variable of type volatile sig_atomic_t.
-
- o+ IEEE Std 1003.1-1988 (POSIX) requires that the fflush
- function specified by X3J11 have some additional
- semantics. The committee confirmed that this was
- indeed allowed by ANSI C.
-
- o+ The IEEE P1003.1 working group had asked X3J11 to
- consider making the symbol "environ" a reserve external
- identifier. This would mean that a ANSI C conforming
- portable application could not use the symbol. This
- request was made because in traditional UNIX
- implementations application launch routines initialize
- this variable to be a pointer to the user's environment
- variable list, and this may not be what a strictly
- conforming ANSI C application would expect. This issue
- was raised before the committee, but found no support
- for a change; the committee response for this was as
- follows:
-
- The ANSI C and IEEE 1003.1-1988 standards are not
- necessarily in conflict here, although it is true
- that in order to avoid the name-space conflict a
- mutually conforming implementation must rely on
- some mechanism such as `global symbolic equate' or
- a zero-size global object `environ' in a separate
- library module immediately preceding the module
- that defines storage for `__environ' (the name
- used by the C run-time startup code). Implementor
- control over the way the linker operates, while
- inappropriate to require for the more universal C
- Standard (hence the constraint on uniqueness of
- external identifiers), is not unrealistic to
- expect for most POSIX implementations. Several
- implementors have in fact indicated their
- intention to provide such a feature.
-
- Another solution, of course, would be to use
- separate run-time startup modules for strict
- ANSI-conforming and vendor-extended (possibly
- POSIX-conforming) implementations, perhaps via a
- compiler flag. This may be useful anyway, for
- hiding extensions in certain standard headers.''
-
-
- - 3 -
-
- Because no substantive changes to the proposed standard
- resulted from the third-round review process, X3J11 voted
- unanimously to submit the standard as edited to reflect
- approved editorial changes to CBEMA X3 as the proposed ANSI
- C standard, pending completion of additional review as
- described below.
-
- The draft Response Document was reviewed first by a small
- group of X3J11 members using electronic mail, then by a
- group meeting at Plum-Hall in Cardiff, NJ on 20-21 Oct.
- 1988. The responses were checked for completeness,
- consistency, and accuracy, and occasionally the original
- responses were changed to achieve those goals, or to meet
- the additional requirement that no unauthorized substantive
- change to the proposed standard could be promised by any
- response. Changes made at the review meeting were
- subsequently edited into the master Response Document. Two
- significant areas of the standard were affected by editorial
- changes resulting from the response review process: The
- description of pointer arithmetic was substantially reworked
- to avoid reliance on an assumption of byte addressability,
- and the specification of the role of type qualifiers was
- rewritten to clarify the significance of what was called the
- ``top type'' (now called ``type category'').
-
- On 1 Nov. 1988, the draft proposed Standard itself was
- reviewed by several X3J11 members in a meeting at Summit,
- NJ. Since the draft already contained the results of the
- Sunnyvale meeting and response review meeting, very few
- changes were found to be necessary at the draft review
- meeting.
-
- On 9 Nov. 1988, the Rationale Document (designed to
- accompany the Standard) was reviewed by a group of X3J11
- members meeting in Cambridge, MA.
-
- On 14 Nov. 1988, copies of all three documents (Response,
- Standard, Rationale) were express-mailed to the 15 X3-
- registered commenters, who have 15 working days (from
- November 18th) in which to reply to X3 if they feel that
- their items were not properly addressed by X3J11. The
- commenters were encouraged to first discuss problems with
- X3J11 members, in hopes of reducing the amount of negative
- feedback to X3.
-
- On 9 Dec. 1988, all three documents plus any feedback from
- the commenters are to be submitted to CBEMA's X3 Secretariat
- as the official X3J11 proposal for the ANSI Standard for
- Programming Language C. After review by X3, assuming no
- problems arise the proposed Standard will then be submitted
- to ANSI for official ratification as an ANSI standard. It
-
-
- - 4 -
-
- seems probable that the final ANSI C standard will be
- published some time during 1989.
-
- The Watchdog contact person in X3J11 is Doug Gwyn. He can
- be reached at:
-
- Doug Gwyn
- US Army Ballistic Research Lab
- 801 L Cashew Ct.
- Belair, MD 21014
- gwyn@brl.mil
- +1 (301) 287-6647
-
-
- Volume-Number: Volume 15, Number 37
-